xerox 19771017 Volume File Map Implementation free download

File name 19771017_Volume_File_Map_Implementation.pdf

Inter-Office Memorandum DRAVf - DRAFT - DRAFf - DRAFf To Pilot group Date October 17, 1977 From Paul McJones, Dave Redell Location Palo Alto Subject Volume File Map implementation Organization SOD/SO XEROX SDD ARCHIVES XEROX Archive: Pi/of 1 have read and understood Pages ______---To --------- Reviewer _ _ _- Date- - - - Filed on: [Ifs]VoIFilMaplmpl.memo , , of Pages Ref .. 11 SOL).. .:;46 The per-volume, self-contained mapping of locally resident files into intra-volume storage addresses is discussed. After a brief motivation, several possible data structures are presented, with our current choices indicated. Introduction A file is the basic information storage object in Pilot [PilotFS]. It has a name, called a file/D, and a state, which is a possibly immutable sequence of zero or more 512-byte pages. A file must physically reside on some one volume (except that copies of immutable files may exist on several volumes), A system element running Pilot will have zero or more directly attached volumes, and may also be connected to a Xerox Wire, allowing access to files on volumes attached to file server system elements. (Pilot requires at least one attached volume or Xerox Wire connection.) Thus algorithms and data structures must exist to find the network location and volume of files specified as operands of Pilot operations. Since fileIDs are intended to be unique across all OIS system elements, one might require that there exist a mapping giving the "address" (network location, volume, and perhaps volume page number) of every filelD. We reject this as unnecessary, undesirable, and probably unimplementable. Instead, every system element will be able to find "local" files. and will solicit the help of a "clearinghouse" to find members of some set of remote files. Here we are concerned with the management of local files. It has been proposed that each system element maintain a single System File Inventory which would map filelDs into (volume, volume page number)'s for all locally attached volumes [PilotC&F]. We feel instead that the data structure supporting this mapping should be distributed across the volumes involved. Thus each volume contains a volume file map, whose primary purpose is to map filelD into volume page number (physical storage address) for each file residing on the volume. Certainly to deserve the classification